Decades ago, cryptography and cryptanalysis were relegated to the backrooms of covert organization such as the United States' Central Intelligence Agency and the United Kingdom's MI-6. Nowadays, however, electronic computing and communication have become so commonplace that everyone it seems is concerned about the sanctity of their computers and the privacy of their data and communications. The ever-increasing popularity of wireless communication has only heightened that concern. As a result, engineers with cryptographic skills are in great demand, and the latest computing and communicating systems are coming to market with cryptographic capability and data security as a cornerstone of their design. Wireless communication devices have certainly obeyed this trend.
To this end, a concept called a Secure Execution Environment, or “SEE,” has begun to find its way into computing and communications systems. An SEE is designed to perform according to the following objectives: (1) programs are authenticated and therefore free of unexpected code before being admitted to run within the SEE, (2) programs and data within the SEE are free from unwanted interference from outside the SEE and (3) programs and data within the SEE cannot be read from outside the SEE. An elaborate authentication process, often involving permissions and digital signatures, is employed to meet all three objectives. Further, components within the SEE are isolated from user-accessible memory, buses or external pins to meet the second and third objectives. For this reason, SEEs are often provided with their own isolated, secure memory and buses. In fact, SEEs are advantageously implemented in Systems-on-a-Chip, or SoCs, allowing user-accessible external pins to be kept to a minimum.
SoC designers wanting to incorporate cryptographic capability into their systems have found SEEs to be a valuable way to ensure that cryptographic keys and processes remain secret. Unfortunately, while cryptography can certainly be carried out securely within an SEE, the data to be provided as input to the cryptographic process must pass securely into the SEE before it is encrypted or decrypted, and then it must pass out of the SEE. From an architectural perspective, the central processing unit is heavily involved in the movement of the data into and out of the SEE, and resource-consuming authentication must be done to ensure that false data are not allowed into the SEE. The result is that cryptography occurring within an SEE comes at a great cost in terms of processing overhead and resulting throughput. If a particular application calls for the encryption or decryption of time-sensitive streaming data or large files (as might well be encountered in a wireless environment), a diminished throughput would be particularly undesirable or even unacceptable.
In an effort to address the overall problem of encryption and decryption speed, hardware cryptographic “accelerators” have been introduced. A cryptographic accelerator uses dedicated cryptographic hardware to perform the same cryptographic functions that a central processing unit would otherwise perform with software. Not only can encryption and decryption be performed faster in hardware than in software, but the computational burden of the central processing unit can also be dramatically reduced, allowing it to perform other important tasks. A cryptographic accelerator may therefore be thought of as a “cryptographic co-central processing unit.” Unfortunately, even with the availability of a cryptographic accelerator, SoC designers are faced with having to choose between placing the cryptographic accelerator within the SEE and continuing to suffer performance penalties by virtue of the required secure data movement, or placing the accelerator outside of the SEE and compromising the secrecy of the cryptographic key or process.
Accordingly, what is needed in the art is a way to achieve a higher encryption or decryption throughput in an SoC than uses a cryptographic accelerator without compromising key or process security.